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rn i hp Specification: 

Please amend the paragraph beginning on page 6, line 4 as follows: 
The preferred embodiment makes use of certain aspects of «NBW*e UNrX°Mike operating 
systems to implement global breakpoints in a less intrusive fashion. In ihe following description, 
a page refers to a unit of main memory. Many modem processor architectures provide facilities 
, and many modern operating systems do, deal with the main memory in fixed size units called 



to 
pages 



Please amend the paragraph beginning on page 6, line 10 as follows: 
The method for inserting global breakpoints includes the following steps: 

1 . To handle breakpoints in pages that arc to be loaded into memory in the future, 
registering a routine to be called when pages for that code module arc loaded into 
physical memory (inod e ->readpage function in fcte JJNUX^ for example). 
This routine inserts all the breakpoints for that page by placing breakpoint 
instructions at specified locations. The debugger must be able to determine which 
breakpoints arc located on a particular page in memory. This information is 
generally available, though the exact way by which the information is obtained 
depends on the method used to specify global breakpoints. 

2. Locating pages of the code module that are already present in memory, and 
inserting the breakpoints in the pages. 

3. Detecting any private copies of pages that may have been created in different 
process contexts that use this module and inserting the breakpoints in those pages. 
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Once inserted, the breakpoints remain there since private pages of executable files 
arc not discarded but swapped to a swap device. 

Please amend the underlined text on page 6, line 30 as follows: 
t4mt* LINUX* Specific ltrm >»mp.nintinn Details (Insertion) 

Please amend the paragraph beginning on ppgc 7, line 31 as follows: 
The executable code segment in memory maps, and is backed by. tbe executable program image 
on the hard disk 134. The executable program imago file 1 02 loaded into memory is represented 
by an operating system data structure, known as the inode in the toJJMlI2£ operating 
system. This inode structure defines the functions that can be used to perform various 
filiated operations on the inode. One of the operations defined by the inode structure is the 
readpage Auction. This function is used to read the contents of the file from hard disk 134 into 
memory. The debugging tool 120 replaces the original readpage function 130 of the inode with 
its own function 124. Whenever the page fault handler 1 12 determines that a page of the 
executable file needs to read into memory, operating in conjunction with the memory manager 
1 14, the page fault handler 1 12 calls the readpage function of the inode, which is now 124. This 
readpage function 124 first calls the original readpage function 130 to actually read the page into 
memory with the assistance of relevant file systems and disk device driven denoted by the block 
132. 

Please amend the paragraph beginning on page 9, line 29 as follows: 
09/732,342 4 
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A code page may possibly be 'dirtied' due to a breakpoint already inserted into the code page 
earlier. While what happens in such cases is operating system specific, many modern operating 
systems (OS), including fcitm* TJNUXf , handle writing to the code segment by making 
private-per-process code pages. This is known as the Copy-Ou-Write (COW) mechanism, the 
consequence of which is that the page is marked as dirty. Once written to, .he code pages do not 
correspond to the executable image file on the hard disk any longer. If these code pages ever 
need to be temporarily removed from the main memory due to the memory pressures, these pages 
are saved on the hard disk (also called the swap device). This process of temporarily removing 
parts of main memory and saving the parts to hard disk for later retrieval, to make more space 
available in the main memory, is called swapping. There is no need to intercept the readpage 
function for this page, since the changes made are written back, saved, in the swap device. 

Please amend the paragraph beginning on page 10, line 29 as follows: 
The loop subprocess 220 is carried out for each of the global breakpoints specified. In block 222, 
using the facilities provided by the operating system (find_page function in to LINUX® 
kernel), the memory page corresponding to a given inode and offset is looked up. The page 
determined by the lookup function 222 is provided to decision block 224. 

Please amend the underlined text on page 12, line 1 as follows: 
i T NT FX® Sreciftr. Tmplemcnlfitinn Details (Removal 

Please amend the paragraph beginning on page 12, line 13 as follows: 
09/732,342 5 
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The method of identifying, inserting, and removing global breakpoints as detailed above has the 
following advantages: 

L Minimally intrusive: the only hook required is in the routine that loads a page of 
code from the executable image. The presence of inodc_opcrations in many 
wWMifee UNIX®-like Operating Systems allows this to be done optimally, 
ensuring that there is no additional overhead when loading pages from executable* 
wilh no breakpoints inserted. 
2. On platforms like himx UNUX! where many page faults can occur, mainly to 
create per-process page table mappings to pages already present in memory, this 
approach is advantageous because spurious page faults do not arise. This method 
allows the debugger to intervene and insert breakpoints at the only place where 
they rue actually necessary, i.e. when the pages arc read into memory. 

3. The problem of reinserting breakpoints when discarded code pages arc brought 
back into memory is seamlessly handled. The Tact that the same inode_operation 
is carried out when reloading discarded code pages makes this possible. 

4. All the code pages with breakpoints are not required to be present in memory 
when inserting breakpoints, nor is this caused to happen, ensuring that 
programatically inserting a large number of breakpoints in one module does not 
cause any significant overhead. 

5. Generally process-level (application) debuggers operate by inserting breakpoints 
on private-per-process code pages. The approach outlined above ensures that the 
global breakpoint facility can function correctly and consistently even in the 
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presence of other debuggers. 

Please amend the paragraph beginning on page 15. line 6 as follows: 
Finally, while the preferred embodiment is implemented using the fchmx LINUX? operating 
system, it will be appreciated by those skilled in the art in view of this disclosure that the 
invention can be practiced with other ******* J I N^-Ukc operating systems, such as Sun, HP, 
and ATX. 

Please amend the paragraph beginning on page IS. line 1 1 as follows: 
The methods according to the preferred embodiment utilise characteristics of the fcrmi* UNUJC* 
operating system. However, the embodiments have application to different operating system, 
requiring some modification. The advantages in terms of efficiency and non-intrusi veness may 
not be achievable to the extent possible in the fcmn* UffilX? OS, in ca.se the other OS does not 
support similar characteristics. The following is a list of significant aspects that are depended on 
at a conceptual level: 

j . The OS provides a mechanism through which the logic that loads code/data into 
memory from a particular file can be hooked into. In WiX=Ukc UNlX^like 
systems (eg. SUN), where there is an evolved virtual file system interface 
enabling specialised file system implementations including filter file systems 
where the low-level file system interface routines can bo overridden or intercepted 
at the granularity of an individual file, this should be possible. 

09/732,342 7 
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On an operating system lite Windows NT, where file system routines may not be 
directly intcrceptablc at individual file level but rather at a drive level, the 
performance is not as good, since there is an extra check happening for all files on 
that file system. 

Also, since the main requirement is to be able to intercept the actual loading of 
code pages from executable files, which are typically mapped into memory, this 
kind of interception has to support memory-mapped input/output (10) situations 
where this loading may be triggered via a page fault. That is likely to be the cose 
wherever support for layered file systems is intentionally built in. 

The OS maintains sufficient information to be able to track down the physical 
pages that have been loaded directly from a particular executable file (i.e. physical 
pages backed by that file). This is likely to be the case on many operating 
systems, where executable code pages are common (read-shared) across all 
processes running that executable. For any new process that is to run the same 
executable, the OS needs this information to cause the necessary mappings to the 
existing loaded pages to occur, 

The OS maintains sufficient information, even if via indirect means, to locate all 
the private-copy pages that have been generated via (he copy-on-write mechanism 
from a given executable page. The indirect means suggested in the preferred 
embodiment depends on the OS maintaining a list of all the address spaces in 
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which portions of a particular file arc mapped and a way to correlate the file 
offsets to the corresponding virtual addresses of the mappings. The former may 
not be supported in some operating systems, like Windows NT. The absence or 
such support or a way to get to the page table mappings in all process contexts 
where a given physical page (backed by a file) is mapped, makes difficult 
providing for invalidation of a particular physical page ir needed. This has some 
ramifications in terms of limitations of the OS, e.g. in supporting cache coherency 
for memory mapped files in distributed file system client implementations. 

On an OS that docs not provide the required support, the embodiments of the 
invention functionality are limited to the extent of not being able to insert global 
breakpoints on existing private-copy pages for that executable. For example, if 
the executable is already being debugged by an application debugger that has 
placed a breakpoint of its own, that particular private-copy page might get missed. 

The remaining assumptions relate to page table based memory management 
approach, and the OS maintaining virtual address range descriptors for each 
address space, which is common to several operating systems. Any OS that 
addresses these aspects can be used for implementing the embodiments of the 
invention. 
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